home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11678 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.2 KB
  1. Path: gambier.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 15 Mar 1996 09:40:50 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4ica32INN5hn@gambier.ugrad.cs.ubc.ca>
  8. References: <00001a73+00002504@msn.com> <Pine.A32.3.91.960313165249.124278B-100000@red.weeg.uiowa.edu> <4i9ld6$m2v@rational.rational.com> <4iah20$p7k@saba.info.ucla.edu>
  9. NNTP-Posting-Host: gambier.ugrad.cs.ubc.ca
  10.  
  11. In article <4iah20$p7k@saba.info.ucla.edu>,
  12. Jay Martin <jmartin@cs.ucla.edu> wrote:
  13.  >rlk@rational.com (Bob Kitzberger) writes:
  14.  >
  15.  >>:   make is a _general_purpose_ utility.  It _can_ be used to manage C 
  16.  >>: projects, or it can be used for a whole host of other things.  How is 
  17.  >>: this hard to understand?  Does ADA provide its own OS, its own editor and 
  18.  >>: its own hardware so that you never need to use anything else?
  19.  >
  20.  >>I don't think that anyone is having difficulty understanding your point.
  21.  >>Make is indeed general purpose, but its roots are in the C/Unix
  22.  >>culture, and those roots show.
  23.  >
  24.  >Right, make is mostly used to support development in C and other
  25.  >primitive languages.  I have seen this piece of crap utility used for
  26.  >all sort of braindead misuses.  Unix-ites seem to love to dp goofy
  27.  >things with their utilities.  Heh, I have seen people using Lex and
  28.  >Yacc to build parsers to read in simple tables.  Like swatting a bug
  29.  
  30. I use Lex and Yacc for scanning simple configuration files and what not? What
  31. is your problem? According to what you are saying, the features of Ada are also
  32. overkill---why not just use hand-coded assembly language? C++ classes? Why
  33. bother, just use static tables for everything!
  34.  
  35. Lex and Yacc are proven utilities that work. 
  36.  
  37. The input file to Lex is far easier to debug and maintain than a hand-written
  38. lexical analyzer.
  39.  
  40. Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar
  41. and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the
  42. keyboard.
  43.  
  44. It's a lot easier to change the grammar and have yacc regenerate new code than
  45. to fiddle with a hand coded recursive-descent or shift-reduce parser.
  46.  
  47.  
  48.  >with a sledge hammer (they ever heard of "scanf"?), but they probably
  49.  
  50. A lex generated scanner is far more robust and _faster_ than scanf(), you twit,
  51. especially if you use GNU flex -f to generate the scanner.
  52.  
  53. I have written a test program in which I compared a flex scanner against
  54. scanf(). The task was to read an eight megabyte file containing eight or nine
  55. digit integers. One program did a loop in which scanf("%d") was invoked.
  56. Another used a lexical analyzer to match the tokens and atoi() to do the
  57. integer conversion. The flex-generated code was almost twice as fast.
  58.  
  59. I have created about half a dozen lexers/parsers in the last year alone, each
  60. of which took the lesser part of an afternoon of fiddling. Some were for
  61. retrieving data out of HTML, others for parsing logs, configuration files and
  62. the like.
  63.  
  64. I replaced one use of scanf() for parsing the entries of a log with a lex
  65. scanner, and improved the CPU efficiency of the program twenty fold!
  66.  
  67. Programs that use yacc are a godsend too! Easy to understand and modify. I can
  68. read the yacc grammar and understand the input language. It's self-documenting.
  69.  
  70. Believe me, these tools have been a wallet-enhancing productivity items. Some of
  71. us have a life.
  72.  
  73.  >felt so Computer Scientific doing it! (The journey is the reward) By the
  74.  
  75. That is completely false. What journey are you talking about? Five minutes of
  76. punching in a simple grammar specification instead of hours of debugging some
  77. silly code only to have it run no faster than an automatically generated
  78. program?
  79.  
  80. The self-indulgent programmer will insist on hand-coding everything. I would
  81. find it a lot more gratifying to write out a grammar on hand, compute the LR(1)
  82. state machine construction and code my own parsing table, and then whip it up
  83. into raw code. That would be my idea of ``journey is the reward''.
  84.  
  85.  >way after 10+ years of using Unix I am having trouble thinking of a
  86.  >standard Unix utility that is not a total misdesigned piece of crap!
  87.  >Maybe someone can help me.
  88.  
  89. A professional counsellor, perhaps.
  90. -- 
  91.  
  92.